Subject: Comments on section 7.2.4 from Paul Brittain

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Fri, 30 Sep 94 14:10:45 EDT

Paul, you are correct about XIDFRAMEs being a problem in CIRCUIT_PENDING
state (ie. no reliable Origin Circuit ID yet).  The 6611 handles this
by interpreting the Data Link ID and finding the associated Origin
Circuit ID.

Should this be the way it is handled in the standard?  Should we drop
XIDs in CIRCUIT_PENDING state until we go to CIRCUIT_ESTABLISHED state?
What is everyone's opinion out there?  Please reply ASAP since time is
short.

>7.2.4. CIRCUIT_PENDING State
>
>      +----------------------+---------------------+----------------------+
>      |        Event         |      Action(s)      |      Next State      |
>      +----------------------+---------------------+----------------------+
>      | Receive CONTACT      | DLC_CONTACT         | CONTACT_PENDING      |
>      +----------------------+---------------------+----------------------+
>      | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
>      +----------------------+---------------------+----------------------+
>      | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
>      +----------------------+---------------------+----------------------+
>      | Receive REACH_ACK    | If Connected:       | If Connected:        |
>      |                      |  Send CONTACT       |  CONNECT_PENDING,    |
>      |                      |                     | else:                |
>      |                      |                     |  CIRCUIT_ESTABLISHED |
>      +----------------------+---------------------+----------------------+
>      | Receive XIDFRAME     | DLC_XID             |                      |
>      +----------------------+---------------------+----------------------+
>      | Receive DGRMFRAME    | DLC_DGRM            |                      |
>      +----------------------+---------------------+----------------------+
>      | Receive DATAFRAME    | DLC_DGRM            |                      |
>      +----------------------+---------------------+----------------------+
>      | DLC_CONTACTED        | If UA is sent in    |                      |
>      |                      | response to SABME:  |                      |
>      |                      |   DLC_ENTER_BUSY    |                      |
>      |                      | else:               |                      |
>      |                      |   no action taken   |                      |
>      +----------------------+---------------------+----------------------+
>      | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
>      +----------------------+---------------------+----------------------+
>      | DLC_XID              | Send XIDFRAME       |                      |
>      +----------------------+---------------------+----------------------+
>      | DLC_DGRM             | Send DGRMFRAME      |                      |
>SCK> Seems like this should be DATAFRAME since we don't have a Origin Data Link
>SCK> ID yet (I can't remember is this came up on the Connect mailer or not).
>
>**PJB> But, using the same arguement, wouldn't we need to remove the ability
>**PJB> to send XID frames until the RA is received as they use the same
>**PJB> routing information?
>**PJB>
>**PJB> The only case where this change is significant is if the partner DLSw
>**PJB> exercises its right to vary the Data Link ID on the REACH_ACK.  It
>**PJB> would either still need to handle the receipt of XIDFRAMEs with the old
>**PJB> ID anyway, so why disallow DGRMFRAME, or both frame types will be lost
>**PJB> until the local retry absorption times out and allows a retry to go
>**PJB> through to the partner again using the new ID from the RA.
>**PJB>
>**PJB> It seems best to continue to use DGRMFRAME, but I'm not strongly
>**PJB> attached to this if everyone else wants to change it.
>
>      +----------------------+---------------------+----------------------+
>      | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
>      +----------------------+---------------------+----------------------+
>
>   The CIRCUIT_PENDING state is entered by the target Data Link Switch following
>   the sending of an ICANREACH message or the sending of a NETBIOS_NR message.
>   this state it is awaiting the reception of a REACH_ACK message from the origi
>   Data Link Switch.  If a connection does not exist with the target station (i.
>   the normal case), the Data Link Switch will enter the CIRCUIT_ESTABLISHED sta
>SCK> Change first sentence to:
>SCK>   The CIRCUIT_PENDING state is entered by the target Data Link Switch follo
>SCK>   the sending of an ICANREACH_cs message.
>
>**PJB> Fine.
>
>   If the target Data Link Switch happens to receive a SABME command from the
>   target station while in the CIRCUIT_PENDING state (i.e., a DLC_CONTACTED sign
>   received from the DLC), the reception of the REACH_ACK message will cause the
>   Data Link Switch to enter the CONNECT_PENDING state and to send a CONTACT
>   message to the other Data Link Switch.  Thus the target Data Link Switch has
>   assumed the role of the origin Data Link Switch.
>SCK> This last sentence seems to be misleading.  The role of origin station and
>SCK> target station (with respect to Circuit IDs) does not change if the target
>SCK> station happens to be the one sending the SABME (which is about half the
>SCK> time).  Does anyone have a problem with it being deleted.
>
>**PJB> I can understand why the sentence was there originally, but still agree
>**PJB> that it should be deleted as it causes confusion.
>

---

From: [email-masked] (Scott Barvick)
Date: Fri, 30 Sep 1994 15:50:20 -0400 (EDT)

We currently drop XIDs in the CIRCUIT_PENDING state.  It has
been too long to remember if we did this on purpose (because
we don't have the info from the REACH_ACK yet) or it was
an oversight in implementing RFC 1434.  Either way, the time
is short in this state, dropped XIDs will be retransmitted, 
and we would probably rather not look around for for the 
Origin Circuit ID based on Data Link ID.  We haven't had any
problems based on this condition, and we actually would have
gotten some "Invalid State" messages so it might be safe to
assume that it is not a big issue to keep on dropping them.

Scott
[email-masked]

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Fri, 30 Sep 94 13:46:45 PDT

> > >**PJB> exercises its right to vary the Data Link ID on the

Paul and Steve,

Could you explain(one last time!) why you need this capability?

Correct me if I am wrong, RFC1434 version sent a CUR on receipt 
of NULL DSAP TEST from the local DLC and
the receipt of ICR triggers the creation of 
local link station control block.
So, the origin switch could only give its ckt id on REACH_ACK.
Also, I am of the impression that the circuit IDs changed 
because of involved SAPS changing.

With the splitting of ex/cs fsms the circuit IDs are created
and local link station control block gets assigned
based on either XID or SABME and also with the real DSAP.
The initial CUR_cs could conceivably carry the ckt/dlc ids.

Also, I presume everyone treats XIDs to NULL SAP as a test
in expl fsm and not start a circuit.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +